오브젝트 - 코드로 이해하는 객체지향 설계 - 조영호

README

이 문서는 단순히 책을 읽어가며 인상깊었던 내용, 궁금한 질문등을 잠깐 계류시키는 용도로 사용할 겁니다. 깨달은 점이나 질문을 구체화 하기 위해선 반드시 별도의 문서를 작성하고 이 문서에 레퍼런스를 걸어주세요.

Scrap

• 상속은 서브타입 관계를 정의하기 위해 사용된다. 대표적으로 서브타입을 식별하는 방식으로는 IS-A 관계를 만족하는지 여부를 보는 것이다. - p.444

  • 언어적인 어휘가 아니라 기대되는 행동에 따라 타입 계층을 구성해야 한다.
  • "레슨 IS-A 예약" 이 문장은 기대되는 행동이 포함되는가? 즉, 예약에게 기대되는 행동과 레슨에게 기대되는 행동이 서로 호환되는가를 평가해보자.

• 리스코프 치환원칙은 상속관계에 있는 두 클래스 사이의 관계를 클라이언트와 떨어뜨려놓고 판단하지 말라고 속삭인다. 상속관계는 클라이언트 관점에서 자식 클래스가 부모 클래스를 대체할 수 있을때에만 유효하다.

  • 대체가능성을 결정하는 것은 클라이언트다. - p.458

• 계약에 의한 설계는 클라이언트가 정상적으로 메서드를 실행하기 위해 만족시켜야 하는 사전조건 (precondition)과 메서드가 실행된 후에 서버가 메서드에게 보장해야 하는 사후조건(postcondition), 메서드 실행 전-후로 인스턴스가 만족시켜야 하는 클래스 불변식 (class invariant)의 세가지 요소로 구성된다. - p.461, p.540 부록_A

  • Precondition: 메서드가 호출되기 위한 서버의 요구, 클라이언트의 의무.
  • Postcondition: 메서드 실행 후 클라이언트에게 보장해야 하는 조건. 클라이언트가 precondition을 만족시켰다면, 서버는 postcondition을 만족시켜야 할 의무가 있다. 만약 그러지 못할 경우, 클라이언트에게 예외를 던져야 한다.
  • Invariant: 항상 참이라고 보장되는 서버의 조건. 메서드가 실행되는 도중에는 불변식을 만족하지 못할 수도 있으나, 메서드를 실행하기 전이나 종료된 후 불변식은 항상 참이어야 한다.

• 서브타입이 슈퍼타입에 정의된 사전조건을 강화하면 기존에 체결된 계약을 위반하게 된다. 따라서 사전조건 강화는 리스코프 치환원칙을 위반한다. 반대로 사전조건을 완화하는 것은 리스코프 치환원칙을 위반하지 않는다. - p.552

• 부모 클래스보다 못한 자식 클래스는 서브타입이 아니다. - p.561

  • 펭귄은 날 수 없다. 새는 날 수 없다. 새는 날 수 있다. 그러면 펭귄은 새인가?

• 너무 이른 시기에 데이터에 초점을 맞추면 객체의 캡슐화가 약화되기 때문에 낮은 응집도와 높은 결합도를 가진 객체들로 넘쳐나게 된다. - p.134

  • 트랜잭션 스크립트와 같은 단순한 CRUD가 주된 모델들은 예외이지 않을까? 여기서 말하는 책임은 대부분 비즈니스 로직과 정책이 들어간 "행동"이 들어가는 모델들이니까.

• INFORMATION EXPERT 정보 전문가 패턴은 객체가 자신이 소유하고 있는 정보와 관련된 작업을 수행한다는 일반적인 직관을 표현한 것이다. 그런데 여기서 말하는 정보는 데이터와는 다르다는 사실에 주의하라. 책임을 수행하는 객체가 정보를 '알고' 있다고 해서 그 정보를 '저장'하고 있을 필요는 없다. 객체는 해당 정보를 제공할 수 있는 다른 객체를 알고 있거나 필요한 정보를 계산해서 제공할 수도 있다. - p.139

  • 모델은 실제 엔티티를 복사해서는 안된다. 도메인 주도 설계 첫걸음-Vlad Kononov#^p47

• LOW COUPLING 어떻게 의존성을 낮추고 변화의 영향을 줄이며 재사용성을 증가시킬 수 있을까? 설계의 전체적인 결합도가 낮게 유지되도록 책임을 할당하라. -

  • 결합도는 의존성이다. 다양한 가짓수의 설계에서 의존성 총합을 줄이는 설계를 선택하라.

• HIGH COHESION 어떻게 복잡성을 관리할 수 있는 수준으로 유지할 것인가? 높은 응집도를 유지할 수 있게 책임을 할당하라 -

  • 응집도는 한 번에 초기화하는 인스턴스 변수의 총합이다. 하나 이상의 이유로 클래스가 변경되어야 한다면 응집도가 낮은 것이다. 클래스의 인스턴스를 초기화하는 시점에 서로 다른 속성들을 초기화하고 있다면 응집도가 낮은 것이다. 메서드 그룹이 속성 그룹을 사용하는지 여부로 나뉜다면 응집도가 낮은 것이다.

  • 2025-05-05 edit) 응집도는 한 객체가 떠안아야 하는 책임의 개수에 비례한다. 너무 많은, 일관성 없는 책임을 하나의 객체에 몰아넣게 되면, 이른바 신 객체를 만들게 되면 이 객체는 응집도가 낮아진다.

• 처음부터 책임주도 설계 방법을 따르는 것보다 동작하는 코드를 작성한 후에 리팩터링하는 것이 더 훌륭한 결과물을 낳을 수도 있다.^p174

• 책임주도설계의 구성요소 inflearn > 오브젝트 - 기초편 > 4-5. 결합도 낮추기 - 변경보호

  • 협력: 한 객체가 다른 객체에게 메시지를 전송해서 도움을 요청하고 응답을 받는 과정을 의미.
  • 책임: 객체가 다른 객체와 협력하기 위해 알아야 하거나 행동해야 하는 것을 의미.
  • 역할: 협력 안에서 책임을 수행하는 대상이다. 객체일 수도 있고, 다수의 객체가 이를 담당하는 일종의 슬롯이기도 하다.

GRASP (General Responsibility Assignment Software Patterns)

정보전문가(Information Expert)

책임을 완수할 가능성이 높기 때문에 정보전문가에게 책임을 할당하는 것이 유리. 여기에서 말하는 정보란, 책임에 필요한 값, 정보를 알고 있는 다른 객체와의 관계, 계산식 보유 등을 의미한다. 따라서 이런 정보전문가 객체에게 책임을 할당하면 추가적인 맥락을 전달할 필요가 줄어들어 결합도가 줄어들게 된다.

창조자(Creator)

책임의 종류가 "생성"일 경우 창조자에게 해당 책임을 할당하라. 어떤 객체가 다른 객체를 사용, 초기화, 포함해야 할 일이 있을때 고려할 수 있다.

낮은 결합도(Low Coupling)

객체 후보군들에 책임을 하나씩 할당해보았을 때 결합도를 계산해보라. 결합도의 총합이 가장 작은 객체에게 책임을 할당하라.

• 결합도 계산법: 결합도 ≈ Fan-in + Fan-out
  • Fan-in: 특정 객체를 호출하는 외부 객체의 개수
  • Fan-out: 특정 객체가 호출하는 외부 객체의 개수

높은 응집도(High Cohesion)

객체가 너무 많은 책임을 지지 않도록 조절하라. god 객체가 탄생하게 되면 모든 관심사와 인지부하가 그 객체에게 쏠리게 된다.

응집도 계산법 (Low Cohesion of Methods)

아래 계산 결과인 LCOM 값이 높을수록 응집도는 떨어진다고 이해하면 된다.

1. 클래스가 가지고 있는 모든 메서드와 클래스의 프로퍼티(멤버변수)의 리스트를 식별한다.
2. 각 메서드가 사용하고 있는 프로퍼티의 관계도를 그래프로 그린다.
3. 그래프를 가지고 서로소 집합 (disjoint set)을 계산한다. 쉽게 말해, 공통되는 쌍이 없는 집합들을 계산한다.
4. 서로소 집합의 수가 하나뿐이면 0, 이외의 경우는 1을 뺀 값이 곧 LCOM이다.

Example

• Attributes: a, b, c

• Methods:

  • method1(): accesses a, b
  • method2(): accesses b
  • methos3(): accesses c

• disjoint set:

  • {method1, method2} accesses b
  • {method3} accesses c

∴ LCOM = 2 - 1 = 1